home *** CD-ROM | disk | FTP | other *** search
- Path: news.nyu.edu!schonberg!dewar
- From: dewar@cs.nyu.edu (Robert Dewar)
- Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu
- Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)
- Date: 9 Apr 1996 07:53:15 -0400
- Organization: Courant Institute of Mathematical Sciences
- Message-ID: <dewar.829050467@schonberg>
- References: <JSA.96Feb16135027@organon.com> <4kb2j8$an0@solutions.solon.com> <4kbrt5$k3h@mulga.cs.mu.OZ.AU> <dewar.829012486@schonberg> <4kcpgkINNcku@keats.ugrad.cs.ubc.ca>
- NNTP-Posting-Host: schonberg.cs.nyu.edu
- X-Newsreader: NN version 6.5.0 (NOV)
-
- Kazimir quoted "Peter's FAQ" as saying:
-
- 1.3: If I write the code
-
- int i, j;
-
- can I assume that (&i + 1) == &j?
-
- A: Only sometimes. It's not portable, because in EBCDIC, i and j are
- not adjacent.
-
-
- I think a smiley is missing here. This is a nice joke, but one can only
- hope that no one thinks that the EBCDIC comment is technically relevant.
-
- Incidentally, the answer that int should always be 64 bits on a 64-bit
- machine is far too facile. This is a very tricky question, which has been
- debated endlessly and no satisfactory solution found. There are very
- delicate tradeoffs to be made between efficiency, functionality, and
- portability here, and the final outcome is far from clear. Lots of C
- programs assume that long is 32 bits. Yes of course they are broken,
- yes of course this was a naughty assumption (of course ther is no way
- in C to get a guaranteed 32-bit integer type, so it is not surprising
- that C code is often broken in this manner). This means that making
- int (and hence long?) 64 bits caues serious porability problems.
-
- Yes, of course I talk about portability problems in a pragmatic sense,
- it is the only useful sense in whch to discuss them, since the discussion
- in purely language terms is vacuuous.
-
-